\section{Abstract}
Dit is het tweede tussentijds verslag voor het vak multimedia ,  van groep SiNT.
 SiNT is een applicatie ontwikkeld voor zowel Apple en Android devices.  Ook
wordt een uitwerking in HTML5 ondersteund.  De bedoeling is een mobiele vorm van
een learning management system (LMS),  zoals Toledo of Moodle,  te ontwerpen.
Tijdens deze eerste iteratie was het de bedoeling om per persoon met \'e\'en
technologie vertrouwd te raken en de applicatie voor de helft uit te werken.  In
de drie technologie\"en werden in eerste plaats vooral de verschillende pagina’s
zoals op het storyboard aangemaakt en ten tweede een connectie met de
\emph{Google App Engine} backend gelegd.
 
\section{Software-ontwerp}
 
%\includegraphics[width=150mm]{diagram1.jpg}
 
\includegraphics[width=150mm]{diagram2.jpg}
 
Bovenstaande figuur geeft een vereenvoudigd EER-diagramma weer
van onze database in de backend.  Deze structuur bouwt verder op de gegeven
backend\footnote{http://hcifetcher.appspot.com}.  Primaire sleutels zijn in het
diagramma weggelaten,  deze zijn bij elke entiteit aanwezig in de vorm van een
\emph{id}.
Eerste en vooral hebben we een nieuwe \emph{Entity} toegevoegd,
\emph{Vraagtopic}.  Deze is onderverdeeld in de vraag zelf en zijn antwoorden.
Een antwoord kan punten ontvangen wanneer wordt aangegeven dat dit een nuttig
antwoord is.  Deze drie entries horen bij precies één vak.  Tussen
\emph{Student} en \emph{Vak} staat een meer-tot-meer relatie,  volgt.  Hierbij
hoort een variabele \emph{punten} die de som van alle punten van een student,
verworven via dat vak,  voorsteld.  Op deze manier is het gemakkelijk de
leaderboards per vak te genereren.  
Een \emph{Achievement} is algemeen en de hiermee verworven punten worden enkel
bij het algemene \emph{leaderboard} in rekening gebracht.  Ten slotte kunnen
\emph{Entities} nog in de TODO-lijst worden geplaatst door ze om te vormen tot
een \emph{TODO-item}.  De TODO-lijst is dan een samenstelling van al de
\emph{Student} zijn \emph{TODO-items}.

Alledrie de technologieën zullen van eenzelfde backend gebruikmaken om
informatie te verwerven.  Op die manier zal de informatie zo consistent mogelijk
blijven.  Momenteel worden nog geen extra entiteiten aan de \emph{datastore}
toegevoegd buiten de RSS en Tweets die automatisch gefetched worden.  
Nog voor we te horen kregen dat we met de \emph{Goolge App Engine} moesten
werken hadden we dit EER-schema al opgesteld.  We hadden de keuze een eigen
relationele databank op te zetten of de GAP te gebruiken.  Aangezien we opgelegd
werden de GAP te gebruiken konden we dit alternatief laten vallen.
 
\section{iOS}
Voor het ontwikkelen van de iPhone applicatie, is er gebruik gemaakt van de
‘storyboarding’ feature, nieuw in iOS5. Deze feature maakt het makkelijker om
een layout voor apps te maken. In de storyboard tool kan je verschillende
schermen (View controllers) en de overgangen tussen de schermen specifi\"eren,
zonder code te moeten schrijven. Alles wordt aangemaakt in een drag-and-drop
omgeving. De ontwikkelaar moet enkel nog de logica achter de controllers
schrijven. Het storyboard van de SiNT applicatie is hieronder weergegeven.
 
\includegraphics[width=150mm]{diagram3.png}
 
De applicatie start met het tonen van een ‘Tab bar controller’, deze wisselt
tussen 2 (later 3, als de TODO lijst geimplementeerd wordt) views, de homepagina
en de vakkenlijst. Als de gebruiker een vak selecteert in de vakkenlijst wordt
de vakpagina van dat vak getoond. Door op het vraag-icoontje te klikken, wordt
de vragenlijst voor dat vak getoond. Als de gebruiker op het twitter-icoontje
klikt kan hij rechtstreeks vanuit de app tweeten (Indien hij zijn Twitter
account ingesteld heeft op de iPhone). Al deze schermen en hun overgangen zijn
gedefinieerd in de storyboard tool en enkel de logica erachter moet
geprogrammeerd worden. Concreet houdt dit in dat Items (blogs, tweets,...)
worden opgehaald en gesorteerd.
 
\includegraphics[width=150mm]{diagram4.png}
 
Dit is het klassediagramma van de iPhone applicatie. Elk scherm heeft zijn eigen
Controller. De homepagina en de vakpagina tonen beide een lijst van items. De
logica van het managen van die lijst van items erven ze over uit
ItemListController. Een ItemListController genereert ItemCells, dit zijn de
cellen in de lijst van items. Item definieert methodes die gebruikt worden om de
ItemCell in te vullen. Blog en Tweet overriden deze en vullen zo de cel op de
gewenste manier in (bv. het tonen van een twitter-icoontje bij tweets en een
blog-icoontje bij blogs).

\section{Android}
De klassestructuur van de android applicatie is zeer samenhangend met het
gekende objectgeoriënteerde programeren. In android wordt er gebruik gemaakt van
activities. Deze staan in voor het werk dat er geleverd wordt op elke pagina.
Elke Activity hangt samen met een xml-file die zorgt voor de layout van de
pagina. Voor de applicatie is er gebruik gemaakt van 1 hoofdklasse, die de tabs
verzorgt. Deze maakt gebruik van TabActivity. Het komt er op neer, dat wanneer
er op een tab geklikt wordt, er een nieuwe Activity gestart wordt en dus een
nieuwe pagina geladen wordt. De TabActivity zorgt er voor dat de tabs bij het
laden van een nieuwe Activity behouden blijven. Dit enkel wanneer er via de tabs
naar een andere activity wordt genavigeerd. De tabs verdwijnen wanneer er naar
een vakpagina wordt genavigeerd. Op de beginpagina (home) wordt er een listview
weergegeven met een twitterstream. Op de vakkenpagina (courses) worden  via een
listview de vakken weergegeven.Omdat deze twee klassen gebruik maken van een
listview, is het aangeraden om ze als ListActivity te implementeren. De
eigenlijke bedoeling van deze implemetatie is voornamelijk om een lijst weer te
geven. Maar er bestaat in Android de mogelijkhead om deze listview een header en
een footer te geven. In de applicatie is bij de beginpagina gebruik gemaakt van
een header waar de foto van de gebruiker, de naam en de score worden
weergegeven. Bij de vakpagina komen in de header de buttons. Per vak is er een
vakpagina dia dynamisch wordt ingeladen. Waar er een vraag gesteld kan worden,
ingecheckt en getwitterd worden. Ook wordt hier een twitterstream weergegeven
die specifiek voor een vak wordt gefilterd. Om de tweets weer te geven op zowel
de beginpagina als op de vakpagina’s, moet er gebruik gemaakt worden van de
ShowTweetActivity waarbij een aparte layout (tweets.xml) wordt aangeroepen om de
tweets weer te geven. In de Activity van de pagina’s kan worden meegegeven welke
url geparsed moet worden. In de implementatie is de klasse Tweet serializable
gemaakt. Deze klasse heeft voorlopig twee eenvoudige string argumenten. De
message van de tweet wordt in de toString() methode meegegeven. 

\begin{center}
\includegraphics[width=75mm]{diagram5.jpg}
\end{center}

De sterkte van deze implementatie is dat alles netjes gescheiden is. Alle
Activities hebben weinig met elkaar te maken. Dus het debuggen van de klassen
verloopt eenvoudiger. Ook is het belangrijk om het juiste type Activity toe te
wijzen. Zo heeft een Activity die werkt met een lijst of tabs, een specifieke
implementatie.

\section{HTML 5}

De HTML5 files zijn slechts in twee bestanden terug te vinden.  Allereerst is er
de \emph{index.html} file die de statische HTML-code bevat.  Verder is er het
\emph{global.js} javascript dat zorgt voor een dynamische invulling van de
inhoud.  Natuurlijk is er achterliggend ook nog de \emph{Google App Engine}
backend zoals besproken in de eerste sectie.

\begin{center}
\includegraphics[width=80mm]{diagram6.jpg}
\end{center}

Deze figuur toont de structuur van \emph{index.html}.  Deze is onderverdeeld in
\emph{div} secties waarvan de \emph{homepage} de belangrijkste is.  
\emph{Homepage} volgt de traditionele \emph{jQuery} structuur en bevat een
\emph{header} en \emph{content}.  In de \emph{header} staat een titel en de
navigatiebalk.  Momenteel kan je enkel nog maar navigeren naar \emph{home, 
vakken} en \emph{todo-lijst}.  Tijdens het navigeren tussen de verschillende
tabs zal steeds de \emph{primary-content} van de \emph{homepage} vervangen
worden.  
Het opstarten van de applicatie of het aanklikken van de \emph{home}-tab zal een
startpagina creëren.  De start- en vakpagina’s zijn allebei opgebouwd uit een
\emph{basicpage-div}.  Ze zijn analoog omdat ze beide een score en een stream
bevatten.  De homepage toont een algemene score en een \emph{stream} met
activiteiten van alle vakken,  terwijl een vakpagina een vakscore en een
\emph{stream} met activiteiten in verband met dat vak bevat.\footnote{met scores
bedoelen we hier de score van de gamification}.  De homepage en een vakpagina
verschillen in het al dan niet weergeven van de \emph{courseinfo-div}.  Deze div
bundelt drie activiteiten, horend bij dit vak:  ‘Stel een vraag’,  ‘Check-in’ en
‘Tweet’.  De drie activiteiten zijn zichtbaar door een titeltje en een icoontje.
 Het aanklikken van het vraagteken\footnote{Stel een vraag} zal een
dialoogvenster openen en de gebruiker toelaten zijn vraag te versturen.  Via een
AJAX-oproep zal de gestelde vraag naar de backend verstuurd worden om op te
slaan.  
Wanneer er op de \emph{todo}-tab geklikt wordt,  zal de \emph{content-primary}
vervangen worden door de \emph{todo}-div.  Deze bevat enkel een lijst die
dynamisch wordt opgebouwd met elementen die teruggevonden worden in de backend
onder de gebruiker zijn \emph{todo’s}.
Het openen van de \emph{vakken}-tab tenslotte,  laadt een nieuwe pagina waarop
een lijst met de gevolgde vakken zichtbaar zijn.  
Bij het aanklikken van een vak zal de \emph{basicpage} worden ingevuld met de
corresponderende vakinformatie zoals hierboven beschreven.  Het laden van een
vakpagina gebeurt op deze manier volledig dynamisch en is grafisch weergegeven
op onderstaande figuur.  

\includegraphics[width=150mm]{diagram8.jpg}

De grootte van de HTML-code is beperkt omdat de meeste informatie ad hoc
verkregen wordt en dus nog moet ingevuld worden.  Het opstarten van de
applicatie zorgt ervoor dat het \emph{Document Object Model,  DOM} meteen alle
pagina’s kent.  Dit zorgt echter niet voor te veel overhead omdat de div’s
beperkt zijn.  Dit is wel niet de beste oplossing.  Zoals op de site van
\emph{jQuery Mobile} staat beschreven is het beter meerdere single-page
templates in plaats van één groot multi-page template te
hebben.\footnote{\url{
http://jquerymobile.com/demos/1.0rc1/docs/pages/page-cache.html}}  Wanneer een
DOM in één keer ingeladen wordt, kan dit voor een bottleneck zorgen.  Zeker in
het geval van \emph{mobile devices} kan dit verbeterd worden.  Beter is pagina’s
te \emph{prefetchen} zodat niet altijd gewacht moet worden wanneer ze dynamisch
worden samengesteld.  Ook het ophalen van \emph{JSON-files} kan op een
efficiëntere manier gebeuren.  Het samenstellen van de activiteiten\emph{stream}
op de hoofdpagina,  omtrent alle vakken,  vraagt veel interactie met de
databank.  Hoewel we slechts een beperkte set van activiteiten tonen worden ze
toch allemaal opgehaald.  Dit zorgt enerzijds voor een vertraging van het
systeem en anderzijds voor een verspilling van de \emph{Google App Engine}
quota.

Deze opdracht heeft ons verschillende dingen bijgebracht. Zo is er het nieuw
soort teamwork dat we ervaren hebben. In een team werken waarin ieder een andere
opdracht heeft, is niet altijd evident. De taken komen grotendeels overeen maar
aangezien iedere persoon in de groep in een andere environment moet werken, is
het moeilijk om synchroon te werken. 
Dankzij de wekelijkse meetings hebben we er voor gezorgd dat we toch ongeveer op
dezelfde lijn gebleven zijn.

Werken met \emph{jQuery} leerde me dat \emph{jQuery} op zicht niet zoveel te
bieden heeft.  Om snel en makkelijk pagina’s te genereren met een handige layout
voor mobiel gebruik is \emph{jQuery mobile} zeer handig.  Verder zijn de
mogelijkheden beperkt.  Om onze app verder uit te breiden was een kennis van
\emph{jQuery,  javascript,  servlets} en \emph{JSP} verreist.  Hierdoor is er
veel tijd verloren om de technologie onder de knie te krijgen.  Andere teams met
meer voorkennis van deze technologieën konden sneller aan hun uitwerking
beginnen en staan op dit moment dus verder dan ons.


Om met Android te leren programmeren heeft toch wat aanpassingstijd gekost. De
Activities die gebruikt worden in Android zijn zeer handig en kunnen zeer
gestructureerd opgebouwd worden. Ook het feit dat de layout van de pagina’s
volledig gescheiden is van de code is zeer nuttig. Dankzij de ontelbare
tutorials die Android te bieden heeft, kan iemand in een mum van tijd vertrouwd
geraken. Bijna elk probleem waarmee er geconfronteerd werd, was er wel een
oplossing te vinden. Toch is er heel wat tijd verloren geraakt met het
implementeren van tabs. 

Het programmeren in iOS ging in het begin vrij stroef, vooral omdat het een voor
mij nog onbekende programmeertaal was. Dit wendde uiteindelijk wel en na wat
tutorials gevolgd te hebben kon ik vrij
gemakkelijk de applicatie implementeren. Vooral de storyboard functie was enorm
handig. Het was simpelweg drag-and-drop en de verschillende schermen en hun
overgangen zijn werkend. Enkel de logica en het invullen van de lijsten moest
nog geprogrammeerd worden. Ook het parsen van de JSON-objecten was zeer
makkelijk. Hiervoor is gebruik gemaakt van de \emph{json-framework}. Voor het
opstellen van tweets is gebruik gemaakt van de standaard
\emph{Twitter.framework} en het was op een tiental lijnen code geimplementeerd.
De iOS omgeving heeft veel uitgebreide libraries waar dankbaar gebruik van
gemaakt werd. Ook de documentatie was zeer compleet.

\section{Status en planning}

In de iOS applicatie zijn momenteel de homepagina en vakpagina’s
geimplementeerd. Tweet- en blogitems worden van de server gehaald en gesorteerd
op datum weergegeven. Er moeten echter nog filters voor de tweet en blogitems
geïmplementeerd worden. Ook kan er getweet worden vanuit de applicatie. Hiervoor
is gebruik gemaakt van de iOS5 ‘Twitter.framework’. Het meeste werk dat nog moet
gebeuren zijn de gamification elementen. Hiervoor zullen we echter eerst de
back-end meer moeten uitwerken. 

De android applicatie heeft momenteel de implementatie van de hoofdpagina en de
vakpagina met twitterstream. Voor de rest moet alles nog geïmplementeerd worden.
Zoals het dynamisch inladen van de vakpagina’s, alle functies van de vakpagina’s
en de gamification. Ook de todo-list moet nog geïmplementeerd worden. Hiervoor
moet ook nog overlegd worden om een structuur op te bouwen om deze functies zo
goed mogelijk te implementeren.

Momenteel zijn in HTML5 de start- en vakpagina’s geïmplementeerd.  Het grootste
werk is nog het invoeren van de gamification.  Hiervoor moet eerst een connectie
met \emph{Twitter} gelegd worden zodat gebruikers kunnen worden geidentificeerd.
 Vervolgens moet de mogelijkheid tot punten uitdelen worden uitgewerkt en de
verschillende \emph{leaderboards} worden gegenereerd.  Antwoorden en Tweets
moeten nog gequoteerd,  achievements aanvaard en check-ins beloond kunnen
worden.  Ook moet het toevoegen van activiteiten aan de TODO-lijst nog worden
uitgewerkt.  Al deze uitbreidingen verwachten ook nog aanpassingen aan onze
backend.

\includegraphics[width=150mm]{mumeGANTT.png}

\section{Tijdsbesteding}
Opmerking:  de uren tijdens de sessies op vrijdag zijn niet in de tabel opgenomen.\\
\begin{tabular}{|r|r|r|r|}
\hline
  & Sander van Loock & Glenn Croes & Koen Dendas\\
\hline
Breinstorm & 4 & 3 & 4 \\
\hline
Scenario & 4 & 2 & 4 \\
\hline
Storyboard & 4 & 4 & 6 \\
\hline
Eigen blog & 2 & 2 & 1 \\
\hline
Blog andere & 1 & 1 & 1.5 \\
\hline
Twitter & 1 & 1 & 1\\
\hline
Verslag 1 & 6 & 2 & 2\\
\hline
Aanleren technologie & 20 & 15 & 10\\
\hline
Programmeren & 50 & 42 & 45\\
\hline
Intern overleg & 4 & 4 & 4 \\
\hline
Verslag 2 & 5 & 4 & 2\\
\hline
Totaal & 101 & 80 & 80.5\\
\hline
\end{tabular}
